<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html>
<head>
	<title>The purpose of Konstrukt</title>
  <link rel="stylesheet" type="text/css" href="documentation.css" />
</head>
<body>
<h1>The purpose of Konstrukt</h1>
<h2>About web applications</h2>
<p>A web application is a program running on a server, which takes input (HTTP-request) and renders an output (HTTP-response). Dynamic, interpreted languages are often used for this. PHP is with its low barrier-to-entry a popular choice.</p>
<p>Traditionally web applications use a HTTP+HTML stack. Or put differently, the HTTP-response contains a HTML-document.</p>
<p class="illustration"><img src="web-application-request-response-lifecycle.png" alt="web-application-request-response-lifecycle.png" /></p><p>New trends (AJAX) extends the concept a bit, since the HTTP-response now can deliver other content-types than the traditional HTML (F.ex. JSON, XML, HTML-fragments).</p>
<p>For most applications, these alternate formats are merely supplements to the traditional HTTP+HTML.</p>
<h2>The presentation layer</h2>
<p>The basic use of PHP is to let the web-server feed a requested file, which has a .php extension, through the PHP-processor. I refer to this approach as <em>Vanilla PHP</em>.</p>
<p>In <em>Vanilla PHP</em> applications there is only one component, involved in rendering the complete view (HTML-document). Although this component may use other components, these are subordinate to the main component. There is a 1:1 relationship between component and response.</p>
<p class="illustration"><img src="component-response-1-to-1.png" alt="component-response-1-to-1.png" /></p><p>While this strategy works fine with simple applications and prototypes, it doesn&#039;t hold in a complex GUI. It soon becomes important to divide the task into multiple components. The benefits of this includes:</p>
<h3>Reusability</h3>
<ul>
  <li>Components can be generalized. F.ex. <code>k_FormBehaviour</code>, <code>k_Datalist</code></li>
  <li>Application-specific components can be reused in multiple places of the application, or in multiple applications.</li>
</ul>
<h3>Flexibility</h3>
<ul>
  <li>Components can easily be moved around within the application.</li>
</ul>
<p class="illustration"><img src="component-response-1-to-many.png" alt="component-response-1-to-many.png" /></p><h2>But there is one problem</h2>
<p>In a HTTP-response, there can only be one HTML-document. Therefore each component needs to be able to both render alone (deliver a HTML-document with appropriate HTTP-headers) or to be used in a context (generate only fragments of HTML).</p>
<p><em>Vanilla PHP</em> has a lot of static/global dependencies. These will need to be decoupled, in order to use a component both alone and in context, without altering it.</p>
<h2>Hierarchical components</h2>
<p>Konstrukt aims to solve this dilemma by encapsulating components. The scope of each component is contained in a context. The context has the interface needed to interact with the HTTP layer, which in <em>Vanilla PHP</em> is corresponds to static functions such as <code>header()</code> and <code>print()</code>, and to global variables such as <code>$_GET</code> and <code>$_POST</code>.</p>
<p>While all components has a context, they can also act as a context for other components. The application thus becomes a hierarchy of component parents and children.</p>
<p>Since all components provides the same interface for their child-components, they can freely be moved around in the hierarchy, or even be used in multiple places. This feature allows for late binding of a component to it&#039;s context, where a parent component can decide its child components at runtime.</p>
<h2>Another Framework?</h2>
<p>The world of PHP provides a plentitude of frameworks, so what sets Konstrukt apart from the rest?</p>
<p>The most important aspect of Konstrukt is to provide a set of rules, by which an application can be built. Thus it must be said to be a framework. It is however of a different kind than what most people associate with a <em>web application framework</em> these days.</p>
<p>Konstrukt is <strong>not</strong> a &quot;full-service&quot; framework in the style of <em>Ruby on Rails</em>, <em>Zend Framework</em> etc. Konstrukt only provides a small subset of what these do.</p>
<p>For example, Konstrukt provides a strategy for URL translation and URL-generation. The strategy is programmable, rather than being configurable/declarative. It takes some more effort by the programmer, but provides much greater flexibility.</p>
<h3>Benefits</h3>
<ul>
  <li>Flexibility</li>
  <li>Reusability</li>
</ul>
<h3>Drawbacks</h3>
<ul>
  <li>The programmer needs to write her own applications</li>
  <li>No scaffolding</li>
  <li>No ORM layer</li>
</ul>
<p>These drawbacks all apply to <em>Vanilla PHP</em>, and as such there is no reason why you couldn&#039;t build a higher level framework on top of Konstrukt, to provide these features. However, the philosophy of Konstrukt, is to allow the programmer to write her own applications, rather than doing it for her. The API doesn&#039;t try to hide or simplify the underlying technology, but rather tries to provide a basic structure to interact with it.</p>
</body>
</html>